An iconic programming system is a "programming-less" environment where programming is done by connecting graphical images of tools (icons), together with connecting lines, to form a directed graph and create an iconic network which represents a software program. The iconic programming system may be used in research and development test environments, where several different electronic instruments are connected to test a system or device. Programming such a system requires instructions to cause the various instruments to perform desired functions in order to operate as a system.
When an iconic programming system is used, each instrument will be represented by a graphical icon, also called a graphical object, and the connections between the instruments are represented by lines between the graphical images. In addition to graphical icons representing instruments in such a system, graphical icons are provided for programming functions, for example looping, IF-THEN statements, etc. By combining instrument and programming icons, a user can create an iconic network involving the programmed operation of several instruments.
Iconic systems are designed to process without a particular order as to which icons process before other icons, except that an icon will not process until all data necessary for its processing is available. When all data is available to several icons, they may process simultaneously. In order to construct iconic systems that function with real world instruments, and which function on a single processor, the icons must process is some defined order. One definition of the order for processing icons is supplied by the conventional rules associated with data flow diagrams.
U.S. Pat. No. 4,901,221 issued Feb. 13, 1990 to Kodosky, et al., and assigned to National Instruments, Inc., is an example of an iconic system which follows the conventional rules associated with data flow diagrams.
An important limitation of such a system, however, is that the conventional rules of data flow diagrams require that iteration operations occur at a sublevel below the iteration icon, and thus any data required within the iteration must be passed to the sublevel by means of formal parameters. For instance, a given program network may have three levels, such as a level 3 FOR-loop is nested inside a level 2 FOR-loop which is nested inside a level 1 FOR-loop, such that the icon for level 1 includes the icon for level 2 which includes the icon for level 3. Iteration at, and passage of data to, a given level is restricted, according to the rules of conventional data flow diagrams, to the level and those below it. Thus, iterating at the level 2 FOR-loop would restrict the user to accessing and viewing only the level 2 and level 3 FOR-loops. Iteration and a complete view of the highest level FOR-loop (level 1) would be restricted. Thus the user is restricted, in iterating and passing data, to the level whose icon is most visually manifest. This is a major limitation of prior art iconic programming systems which adhere to the conventional rules of data flow diagrams.
There is a need in the art for a method for defining the order of processing of icons in an iconic programming system that allows processing of iterations while allowing the icons of all iterations to appear at the same level of an iconic network.